\chapter{Architecture des bases de données}

\section{Base de données interne}

\subsection{Diagramme d'entités-relations}

\begin{center}
\includegraphics[scale=0.67]{schema_relationnel_bdd_interne}
\end{center}

\subsection{Explications}

La base de données interne de SPASS est celle qu'utilisera le Core pour stocker toutes les données nécessaires au fonctionnement de ses services. Il n'y aucune gestion de droits dans cette base, elle interviendra dans la base de données externe qui sera détaillée dans la section suivante.

\subsubsection{Présentation des tables}

\textbf{Template} : Cette table va permettre de répertorier tous les \textit{template} disponibles pour les \textit{assignment}, elle devra être tenue à jour à chaque ajout, modification ou suppression de \textit{template}. Pour chaque entrée de cette table un certain nombre d'informations seront stockées comme le titre (ex: Projet, Devoir Maison, Td, Mini-Projet etc ...), la durée, l'effectif minimal et maximal de chaque groupe d'étudiants (\textit{team}).

\textbf{Test} : De manière similaire à la table \textit{template}, \textit{Test} répertoriera l'ensemble des tests disponibles. Chaque entrée représentera un test, et à chaque test sera associé une succincte description, le langage auquel il est rattaché (ex: C pour Valgrind), et son adresse physique dans la \textit{Warehouse}.

\textbf{Test\_Script} : Une entrée dans cette table correspond aux informations contenu dans un script. En d'autres termes, une entrée contient une séquence de tests à effectuer. Cela permet d'éviter d'avoir à re-parser le fichier de script à chaque exécution.

\textbf{Test\_Set} : Cette table n'introduit pas vraiment de nouvelles données, elle associe un ensemble de scripts de tests à une même clé, elle permet de simplifier la base de données et de n'associer qu'une clé (un ensemble de scripts de tests) à chaque \textit{assignment} plutôt que plusieurs (une par scripts de test). Elle a surtout l'avantage de ne pas fixer de limite au nombre de scripts de tests associés à un \textit{assignment}, ce qui serait le cas si la table \textit{assignment} devait stocker elle même l'ensemble des tests de scripts rattachés à chacune des entrées.

\textbf{User} : Cette table stocke tous les utilisateurs du système, elle n'introduit aucune gestion de droits, et donc à ce stade il n'y aucune distinction entre les enseignants et les étudiants.

\textbf{Team} : C'est la table qui permet d'associer les utilisateurs (étudiants) au sein d'un même groupe. Typiquement les étudiants associés à la même clé (\textit{id\_team}) font parti du même groupe. Faîte ainsi, la table ne rencontre aucune difficulté à associer un étudiant à plusieurs groupes.

\textbf{Team\_Set} : A l'instar de \textit{Test\_Set}, cette table permet d'associer plusieurs groupes afin de former un ensemble. Ainsi on choisi d'associer un unique ensemble de groupes à chaque \textit{assignment} plutôt que de fixer un nombre de groupes maximal au système. Cette solution a l'avantage d'être souple, on peut retirer ou ajouter une équipe à un \textit{assignment} en ne modifiant que cette table.

\textbf{Assignment} : C'est la table centrale de cette base de données, elle associe à chaque entrée un \textit{template}, un enseignant (\textit{user}), un ensemble de tests (\textit{Test\_Set}), ainsi qu'un ensemble de groupes d'étudiants (\textit{Team\_Set}). 

\subsubsection{Interaction avec la base de données externe}

La base de données interne n'introduit pas la gestion des droits, elle est cependant auto-suffisante à l'interface par ligne de commande où l'utilisateur connecté a de facto tous les droits. Cependant pour une exploitation complète du système par une interface conviviale, comme notre interface web, il est nécessaire d'introduire une gestion des droits pour différencier les utilisateurs durant leur connexion au système. \textit{Django} dispose d'une gestion des droits particulière. Il utilise le modèle (le code de notre Core) pour générer automatiquement l'ensemble des droits (expliqué en détail dans la section suivante). Pour associer chaque utilisateurs à un groupe de droits, il dispose de sa propre table \textit{user} qu'il va falloir synchroniser avec la table éponyme de la base de données interne.

\newpage

\section{Base de données externe}

\subsection{Diagramme d'entités-relations}
\begin{center}
\includegraphics[scale=0.70]{schema_relationnel_bdd_externe}
\end{center}

\subsection{Explications}

La base de données externe est celle qu'utilise l'interface web gérée par \textit{Django}. C'est la seule base de données qui introduit la gestion des droits d'accès. Pour ce faire, elle utilise principalement deux tables, \textit{User} et \textit{Group} présentées ci dessus.

\subsubsection{Présentation des tables}

\textbf{User} : C'est la table qu'utilisera \textit{Django} pour authentifier les utilisateurs, une grande partie des champs sont similaires avec la table éponyme de la base de données interne. Un nouveau champs \textit{id\_group} fera son apparition, il permettra d'associer chaque utilisateur à un groupe de droits dans la table \textit{Group} permettant ainsi de distinguer les utilisateurs connectés et de leur offrir le panneau de services associés à leurs privilèges.

\textbf{Group} : C'est dans cette table que seront créés les différents groupes d'accès (enseignants, étudiants etc ...). La gestion des droits introduite par \textit{Django} est liée au modèle utilisé (les services du Core), un droit correspond à la permission d'appeler une fonction ou une méthode. L'ensemble des droits est généré automatiquement par \textit{Django} à partir du modèle. Un groupe est créé en associant un certain nombre de droits (appels aux fonctions ou méthodes) à un nom de groupe (ex: Teacher, Student etc ...) et une à clé \textit{id\_group}. Cela se fait par l'interface administrateur de \textit{Django}.

\subsubsection{Interaction avec la base de données interne}

Pour que cette base de données puisse fonctionner correctement, il faut que sa propre table \textit{user} et celle de la base de données interne soient synchronisées. Pour se faire, on pourra automatiser la tache en faisant un appel aux deux tables pour chaque insertion ou modification, ou alors synchroniser l'ensemble des entrées à intervalles de temps régulier.
